Methods and systems for controlling addressable lighting units

ABSTRACT

Systems and methods that provide improved control of addressable lighting fixtures. Individual lighting units have assigned schedules defining the power levels for the unit at various times of the day. Adjustments to a scheduled level for each unit may be made depending on predefined exceptions, ambient daylight, conservation commands, override instructions, and boost signals. Individual occupants of the building are associated with sets of individual lighting units. An override command received by the system and associated with a particular individual occupant is applied to the individual lighting units with which the individual occupant is associated.

CLAIM OF PRIOR APPLICATION

This application claims the benefit of U.S. provisional patentapplication No. 60/887,375, filed on Jan. 31, 2007.

FIELD OF THE INVENTION

The present invention relates to methods and systems for controllingaddressable lighting units, and, in particular, to methods and systemsfor controlling and managing a plurality of lighting units in a buildingor other facility.

BACKGROUND OF THE INVENTION

Building management systems have become increasingly sophisticated toprovide better control over lighting schemes and to improve energyconservation.

In many industrial and office buildings, lighting is governed by aschedule such that it turns on and off at specific times of day or onspecific days. For example, the lights may be configured to turn on at acertain time in the morning, such as 6 a.m. local time, and turn off inthe evening, for example at 7 p.m. In some cases, the schedule willprovide for different lighting schemes. By way of example, all lightsmay be fully on during the working hours and off in the night and onweekends, but may be reduced to 50% dimmed status for a few hours in theevening at times when cleaning staff may be present in the building.

In addition to scheduled control of lighting, individual units orsections of units may adjust their dimming levels based on a lightsensor present in the area of the units in order to take advantage ofnatural light in areas near windows to conserve energy. Typically, thelight sensor is directly connected to one or more of the units andprovides the units with an indication of the natural light levels. Theunits dim their scheduled levels based on the readings from the lightsensor.

Systems exist that allow occupants to override a lighting schedule, forexample if an occupant is working late or on weekends during a time whenthe lights are normally dimmed or off. Typical systems allow an occupantor a building supervisor to input a command to the lighting controlsystem through a touch-tone telephone system, a Web interface, orthrough some other user input interface. The command may instruct thesystem to turn on the lights for a particular floor or, if the floor issufficiently large to be divided into sections, in a particular sectionof the floor. To the extent that the occupant requires access to morethan one section or floor, the occupant instructs the system to turn onthe lights in multiple sections or floors. The override command may beassociated with a time-out value, such that the scheduled dimming or offstatus resumes after a preset time period, such as for example 2 hours.

It would be advantageous to provide for improved methods and/or systemsfor controlling addressable lighting fixtures.

SUMMARY OF THE INVENTION

The present application describes systems and methods that provideimproved control of addressable lighting fixtures.

In one aspect, the present application discloses a system forcontrolling addressable lighting units within a building, the buildinghaving at least one tenant, the tenant being associated with a pluralityof occupants, the units each having one or more light fixtures, and eachunit having an addressable switch connected to a control bus. The systemincludes a controller having one or more control outputs fortransmitting commands to the units via the control bus, and a memorydevice. The memory device includes a unit record for each unit, eachrecord specifying unit-specific properties, and an occupant record foreach of the occupants, the occupant record identifying one of theoccupants and associating one or more of the units with the identifiedoccupant.

In another aspect, the memory of the foregoing system may, in somecases, include one or more Work Points, each Work Point identifying oneor more units. The memory may further contain an association between oneof the occupants and one of the Work Points, and the system may includean override module for receiving an override command associated with theone of the occupants and for causing the units within the one of theWork Points to be set to an override power level based on theassociation.

In yet another aspect, the present application describes a system forcontrolling addressable lighting units within a building, the buildinghaving at least one tenant, the tenant being associated with a pluralityof occupants, the units each having one or more light fixtures, eachunit having an addressable switch connected to a control bus. The systemincludes a controller having one or more control outputs fortransmitting commands to the units via the control bus and beingconfigured to receive an instruction associated with one of theoccupants; and a memory device storing a unit record for each unit, eachrecord specifying unit-specific properties, an occupant record for eachof the occupants, each occupant record identifying one of said occupantsand associating a subset of the units with the occupant, wherein thecontroller is configured to generate the commands to the subset of theunits in response to the light instruction and based on the associationin the occupant record between said one of the occupants and the subsetof the units.

In a further aspect, the present application describes a method forsetting light levels for addressable lighting units within a building,the building having at least one tenant, the tenant being associatedwith a plurality of occupants, the units each having one or more lightfixtures, each unit having an addressable switch connected to a controlbus. The method includes receiving a lighting instruction associatedwith one of the occupants; reading an occupant record identifying saidone of the occupants and associating said one of the occupants with asubset of the units; and generating commands to the set of units inresponse to the lighting instruction and based on the association in theoccupant record.

In another aspect, the present application discloses a method forsetting light levels for addressable lighting units within a building.The method includes associating a schedule with each lighting unit, eachassociated schedule defining power levels for the unit for specifictimes of day; and for each lighting unit, determining a current powerlevel for the unit based on its associated schedule and a current timeof day, and instructing the unit to user the current power level.

In yet another aspect, the present application provides a system forsetting light levels for addressable lighting units within a building.The system includes means for associating a schedule with each lightingunit, each associated schedule defining power levels for the unit forspecific times of day; means for determining, for each lighting unit, acurrent power level for the unit based on its associated schedule and acurrent time of day; and means for instructing the unit to use thecurrent power level.

In a further aspect, the present application provides a system forcontrolling addressable lighting units within a building, the units eachhaving one or more light fixtures, and each unit having an addressableswitch connected to a control bus. The system may include a lightcontrol interface having one or more control outputs for transmittingcommands to the units via the control bus, a control module fordetermining a power level for each unit and for causing the lightcontrol interface to send power level commands to the units, and a lightsensor located external to the building and having an output incommunication with the control module for providing light level data tothe controller. The system also includes a memory device storing a unitrecord for each unit, each record specifying unit-specific propertiesincluding a daylight savings weight, wherein the daylight savings weightassociates light levels with power levels for the unit. The controlmodule includes a component for determining a daylight level based onthe light level data and a component for determining the power level foreach unit based upon the daylight level and the power level associatedwith one of the light levels corresponding to the daylight level.

In a further aspect, the above system may also include an interiorsensor for determining the status of one or more blinds, and the controlmodule may be configured to adjust the power level of one or more unitsbased on the status of the one or more blinds.

In yet another aspect, the present application discloses a system forcontrolling addressable lighting units within a building, the units eachhaving one or more light fixtures, each unit having an addressableswitch connected to a control bus. The system may include a lightcontrol interface having one or more control outputs for transmittingcommands to the units via the control bus, a control module fordetermining a power level for each unit and for causing the lightcontrol interface to send power level commands to the units, and amemory device storing a unit record for each unit, each recordspecifying unit-specific properties including a load shedding weight,wherein the load shedding weight associates emergency levels with powerlevels for the unit. The system also includes a conservation demandmodule for implementing conservation demand instructions, the modulecomprising a component for receiving a conservation demand associatedwith a selected one of the emergency levels, and for causing the controlmodule to set the power levels for at least some of the units based uponthe power levels associated with the selected one of the emergencylevels.

Other aspects and features of the present invention will be apparent tothose of ordinary skill in the art from a review of the followingdetailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanyingdrawings which show an embodiment of the present invention, and inwhich:

FIG. 1 shows, in block diagram form, an embodiment of a control systemfor addressable lighting units within a building or other facility;

FIGS. 2 and 3 both diagrammatically show embodiments of the system ofFIG. 1 implemented over a local area network;

FIG. 4 shows, in flowchart form, an example method for determining orsetting the lighting level of a Unit;

FIG. 5 shows a floorplan for a portion of an example building;

FIG. 6 shows the floorplan of FIG. 5 with an example of a Work Point;

FIG. 7 shows another example of a Work Point with regard to thefloorplan of FIG. 5;

FIG. 8 diagrammatically shows a portion of the floorplan of FIG. 5 withoverlapping Work Points;

FIG. 9 shows, in flowchart form, another example method for determiningor setting the lighting level of a Unit;

FIG. 10 shows, in flowchart form, an example method for implementingoverride commands for overlapping Work Points;

FIG. 11 shows, in flowchart form, a further example method fordetermining or setting the lighting level of a Unit; and

FIG. 12 shows, in flowchart form, a method of conservation demandmanagement with respect to a lighting system.

Similar reference numerals are used in different figures to denotesimilar components.

DESCRIPTION OF SPECIFIC EMBODIMENTS

In some example embodiments below a control system is described forcontrolling lighting units in a building or other facility. It will beappreciated that the control system is not limited to installationswithin a single building. The control system may be employed to controlmultiple buildings, for example as part of a campus or industrial park.The buildings need not be associated or even co-located. Moreover, thecontrol system may be used to control lighting units disposed indoors oroutdoors. For example, the control system may be used in connection withstadiums, convention centers, parks, or any other indoor/outdoorfacilities. The control system and/or the lighting units are notintended to be limited to use in association with any of the buildingsor facilities described herein.

In the case of addressable lighting systems, there are a number ofstandards and protocols for control signaling. Each lighting unit mayinclude an addressable ballast and one or more lighting fixtures. Theaddressable ballast may connect and disconnect the fixtures from thepower mains. In many cases, the ballast may regulate voltage or currentapplied to the fixture to control dimming. The various ballasts that maybe used in an addressable lighting system will be appreciated by thoseof ordinary skill in the art, and it will be understood that the presentinvention is not limited to any particular type of ballast or fixture.

Addressable lighting systems typically include an interface or protocolto transmit commands over links to particular units. Example commandsmay instruct a unit to turn on, turn off, or dim to a certain percentageof full power. In some cases, the following description may refer to a“power level” or “dimming level”. Although a “power level” might imply apositive percentage of full power and a “dimming level” might imply anamount by which a unit should be reduced from full power, the use ofeither implementation is application-specific and the presentdescription may use the terms interchangeably. Other commands will beunderstood by those skilled in the art of addressable lighting control.

One protocol for interfacing with lighting units is the DigitalAddressable Lighting Interface (DALI) standard. While embodiments of thecontrol system described below may use a DALI bus for sending commandsand receiving data from lighting units, those skilled in the art willappreciate that other control standards, protocols, or interfaces may beused in other embodiments.

Control System

Reference is first made to FIG. 1, which shows, in block diagram form,an embodiment of a control system 10 for addressable lighting unitswithin a building or other facility. The control system 10 includes amaster controller 12 and one or more subcontrollers 14 (shownindividually as 14 a, 14 b, . . . , 14 n). The master controller 12 isconnected to a non-volatile memory, which in one case is configured as adatabase 16. The master controller 12 may also be connected to a displaydevice 18. The display device 18 may comprises a graphical userinterface (GUI) for displaying information to a user and for receivinguser input and commands.

The configuration of the control system 10 allows for significantdistributed processing of the various commands and controls related toaddressable lighting. Each subcontroller 14 controls the state of a setof lighting units. In one embodiment, the set of lighting units may becommon to a floor of the building, such that each subcontroller 14 isspecific to at least one floor; although it will be appreciated that thedivision of sections of the building or facility amongst thesubcontrollers 14 need not be by floor. In one example embodiment, thecontrol system 10 may have a single subcontroller 14.

Each subcontroller 14 determines the state of each unit under itscontrol and provides instructions to the units. In particular, thesubcontroller 14 outputs commands to a lighting control interface 24. Inone embodiment, the lighting control interface 24 may be implemented inaccordance with a standardized interface protocol, such as the DALIprotocol; however, the interface 24 may be proprietary in someembodiments. The lighting control interface 24 is connected to one ormore control buses 26, which are connected to the lighting units. Thelighting control interface 24 includes a bus controller for powering thecontrol buses 26 and transmitting command instructions on the controlbuses 26. The command instructions may, for example, direct one or moreof the lighting units to turn off, turn on, or dim to a specified powerlevel.

The lighting control interface 24 receives instructions from thesubcontroller 14 and, in some embodiments, may provide feedback data tothe subcontroller 14. Some embodiments of the lighting control interface24 may receive feedback information regarding the state of the lightingunits and may relay the feedback information to the subcontroller 14.The subcontroller 14 may also include one or more input ports connectedto one or more inputs 30 for receiving data regarding the lightingenvironment. Example inputs include sensors, switches, buttons, etc. Theinputs 30 may, for example, include light sensors that output an analogsignal representative of the ambient light level in the area of thesensor.

In one embodiment, each subcontroller 14 may be implemented as a daemon22 and a control module 20. The daemon 22 is a background process orservice that manages communications between the control module 20, thelighting control interface 24 and the various other components of thesystem 10, including the master controller 12.

The control module 20 determines the status of each lighting unit underits control at any point in time. It performs the necessary calculationsto determine the dimming level for each unit dependent upon the time andthe current schedule, taking into account any overrides, exceptions,etc., as will be described in greater detail below.

The database 16 contains data regarding the lighting units, theirproperties, their association with a particular subcontroller 14, theirdimming schedule, and additional information, as will be described ingreater detail below. The data for lighting units associated with aparticular subcontroller 14 is uploaded to the control module 20 via thedaemon 22 upon initialization of the system 10. The control module 20performs the function of determining the status and dimming level ofeach unit and issuing the necessary commands to the lighting units, viathe daemon 22.

The master controller 12 provides users with a high level command setfor managing the control modules 12. For example, the master controller12 may stop, start, or reconfigure each of the control modules 20. Also,through the display device 18, a user or administrator may requestreports, request overrides, and issue load shedding commands, amongother things. The master controller 12 may also be accessible by aremote client 32 via a network 28. The network 28 may include a LAN,WAN, WLAN, any combination thereof, or any other data network, includingthe Internet. The remote client 32 and/or GUI display 18 may beimplemented on a variety of devices, such as, for example, a personalcomputer, a handheld wireless device, a personal digital assistant, orany other suitable computing device.

Reference is now made to FIGS. 2 and 3, which both diagrammatically showembodiments of the system 10 implemented over a local area network (LAN)50. In both cases, the control modules 20 are implemented on separatemachines from their corresponding daemons 22. In the embodiment shown inFIG. 2, the inputs 30 and the lighting control interface 24 rely onRS232 serial ports 36. Accordingly, the daemon 22 is implemented on thesame machine as the serial ports 36 with which it is to interface. Itwill be appreciated that the GUI 18 does not necessarily run on the samemachine as the master controller 12.

In FIG. 3, the lighting control interface 24 is a DALI bus interfaceimplemented using an Ethernet-enabled programmable logic controller(PLC). Accordingly, the lighting control interfaces 24 and the daemons22 are shown in FIG. 3 as being implemented on separate machines, allconnected to the LAN 50.

It will be appreciated that the system 10 architecture is such that itmay be as distributed as the application demands. In some cases, thesubcontrollers 14, including the daemons 22 and the control modules 20,may be implemented on a single machine. In others, each subcontroller 14may be on a different machine. In still others, the daemons 22 may runon different machines from the control modules 20. In yet otherembodiments, the daemons 22, control modules 20, and master controller12, may each be implemented on any machine reachable by way of Ethernetconnection. For example, one embodiment of the system 10 may include adaemon 22 located in Australia, a control module 20 located in Canada, amaster controller 12 located in the United States, and a remote clientGUI located in the United Kingdom, all connected via the Internet.

It will also be appreciated that the architecture of the system 10permits easy scalability, whereby additional subcontrollers 14 may beadded to an existing installation.

Control System Operation

To assist with understanding the following description of the controlsystem's operation, a set of terms will be defined.

A “Unit” refers to a lighting unit 28, which is the smallest granularityin the control architecture. The lighting unit has a unique address. TheUnit may include more than one ballast and each ballast may include morethan one lamp. Each Unit has a set of properties, some of which are“hard” properties not inherited from a parent grouping, and others maybe “soft” properties that are inheritable from a parent grouping. If a“soft” property is explicitly defined for a Unit, then the explicitlydefined value applies; otherwise, it inherits the value of the parentgrouping. Parent groupings may be made by area, floor, building, or atother levels depending on the specific implementation.

A “Schedule” refers to a set of times and light levels. The light levelsare indicated by a percentage of full power for a Unit. For example, alight level may be 50% of full power. Each Unit, or group of Units, mayhave a Schedule assigned. An example Schedule includes one or more timesand a light level corresponding to each time. For example, a Schedulemay take the form:

-   -   [9:30 70] [18:15 40] [19 0]

This example Schedule indicates that at 8 a.m. the light level should beset to 50% of maximum. At 9:30 a.m. the light level should be set to 70%of maximum, and at 6:15 p.m. the light level should be reduced to 40% ofmaximum. At 7 p.m. the light should be turned off.

An “Exception” is a predefined property that overrides the Schedule.Exceptions are generally related to the date or day. Exceptions mayspecify a date or categories of dates and a schedule. Exceptions may beused, for example, to provide a different Schedule for weekends orholidays. In one example embodiment, the dates for an Exception may beencoded as follows:

Day of the week: /1 to /7 = Sunday to Saturday Month: 1 to 12 Year: 01onwards

Example dates may be [/7], which would indicate the Exception appliesevery Saturday; [25 12], which indicates Christmas Day; and [15 06 07],which indicates Jun. 15, 2007.

A “date” within an Exception may be combined with a schedule property todefine the Exception. For example:

scheduleOff = [0 0] [/1] scheduleOff indicates the lights should be offevery Sunday [4 7] sheduleOff indicates the lights should be off everyJuly 4th

The term “Boost” refers to a signal generated by a physical pushbuttonor switch the lighting environment (a “hard” boost) or a signalgenerated by a software request (a “soft” boost). The software requestmay, for example, be initiated through an icon that the user clicks inan interface. The Boost signal is a specific override request associatedwith a predefined set of lights. For example, a physical pushbutton mayhave its boost signal associated with a set of Units in physicalproximity to the pushbutton. In another example, an occupancy sensor maygenerate a boost signal.

The term “Proxy” is a predefined property of a Unit or group of Unitsthat prescribes the response of the Unit or group of Units to a specificBoost signal. The Proxy property may include both a power level orlighting level at which the unit(s) is to be set in response to a boostsignal, and a duration for which the boost is to last. For example, in awashroom at a time during which the lights are scheduled to be off, alight switch or occupancy sensor may be activated to supply a boostsignal. The Units within the washroom may have a Proxy property of theform [80 15] [40 5]. This property specifies that the lights are to beturned on to an 80% power level for fifteen minutes when a boost signalis received. Following expiration of the first fifteen minutes, thelights are to be dimmed to a 40% power level for five minutes. Finally,following the five minutes, they are turned off.

In addition to these properties or parameters, each Unit may haveassociated layout parameters, specifying its location. In some cases,the control system 10 may include graphical representations accessiblethrough, for example, the GUI 18 through which the physical layout ofvarious lighting units may be visually displayed. Individual units maybe selectable within the GUI 18 layout to obtain data regarding theunit's properties and status. Other properties or parameters that may bedefined or associated with each Unit include:

-   -   Watts=maximum power consumption    -   Minimum=minimum power level    -   Maximum=maximum power level    -   Scheduled Level=determined by Schedule and current time    -   Current Level=current operating level of the Unit

Additional parameters, variables, or properties may also be used, someof which are discussed in further detail below.

It will be appreciated that different implementations of the controlsystem 10 may structure the properties in different manners. The precisedata structure used to define the properties of Units and theirassociation with a group of other units, specific boost signals, etc.,may change depending on the embodiment.

Reference is now made to FIG. 4, which shows, in flowchart form, anexample method 80 for determining or setting the lighting level of aUnit. In one embodiment, the method 80 may be implemented by way ofsoftware operating within the control module 20 (FIG. 1) associated witha specific lighting unit (FIG. 1).

The method 80 represents the setting or determination of the CurrentLevel for a particular Unit. In some embodiments, the control module 20may perform the method 80 at fixed intervals, such as every second,every ten seconds, etc. In other embodiments, the control module 20 mayperform the method 80 based on triggers, such as interrupts or othertriggers, set within the control module 20 using time values, likeexpiry of a duration, or the input of a boost signal. Otherpossibilities will be appreciated by those skilled in the art.

The method 80 begins in step 82 with retrieval of the Schedule for theparticular Unit. The Schedule may be uploaded to memory within thecontrol module 20 during an initialization or start-up phase. TheSchedule may be retrieved from memory and, based on the current time,the control module 20 may determine the Scheduled Level for the Unit. Instep 84, the Current Level is set to the Scheduled Level.

In step 86, the control module 20 may assess whether the Current Level,i.e. the Scheduled Level, is more than a Maximum prescribed for theUnit. If so, the Current Level is reduced to the Maximum Level in step88. In another implementation, the Current Level is set to the minimumof the Maximum and the Scheduled Level.

In step 90 the control module 20 determines whether an Exceptionapplies. Typically, this involves comparing current date informationwith the relevant Exceptions associated with the Unit, to determinewhether an Exception applies. If so, then in step 92, the Current Levelis set based on the level specified in the Exception. Otherwise, theCurrent Level remains the same.

In step 94, the control module 20 assesses whether a boost signalapplies. The Proxy property corresponding to a Unit may specify a powerlevel and duration for a boost signal. When the boost signal isreceived, the control module 20 may set the parameter Boost Signal basedon the specified power level. The parameter may be reset when the boostcondition/duration expires. Accordingly, in step 94, the control module20 determines whether a boost condition has occurred, meaning theprescribed duration has not expired. If so, then in step 96, the CurrentLevel is set based on the power level prescribed in the Proxy propertyor by the Boost Level property.

In step 98, the control module 20 may assess whether the Current Levelis below a Minimum set for the Unit. If so, then the Current Level israised to the Minimum in step 99.

The resultant Current Level is then used to construct and issue acommand via the lighting control interface 24 to set the dimming levelof the Unit. In many embodiments, the previous Current Level may bemaintained in memory and instructions only issued through the lightingcontrol interface 24 in the case where there is a change in the CurrentLevel for a Unit.

In some embodiments, it will be appreciated that the parameters, likeBoost Level or Scheduled Level, may represent a percentage of the Unit'smaximum power. In other embodiments, one or more such parameters mayrepresent a dimming level. For example, a Boost Level of 40 mayrepresent 40% of maximum power in some embodiments, or may represent adimming factor of 40% from maximum to result in a 60% level of maximumpower.

Another example of the method of determining or setting Current Levelfor a Unit may be represented in pseudo-code as follows:

-   -   Level=min (Scheduled Level, Maximum)    -   Level=min (Level, ExceptionLevel)    -   Level=min (Level, 100−BoostLevel)    -   CurrentLevel=max (Level, Minimum)

In this example, the parameter ExceptionLevel represents the power levelspecified in an applicable Exception, if any, and the parameterBoostLevel represents the dimming level specified in the Proxy propertyassociated with the Unit, if any.

Based on the foregoing description, other example methods and algorithmsfor determining the Current Level of a Unit will be appreciated by thoseskilled in the art.

Overrides

In addition to controlling the lighting units by way of a preprogrammedschedule, the control system 10 permits a user to override the schedule.An override is typically required to turn on lights at a time when thelights are off or dimmed. For example, at night or on weekends a usermay require the lights in his or her area in order to continue working.In some existing control systems, the floor may be divided into sectionsand the user may request, through a user interface, that particularsections be illuminated. The request may be associated with a predefinedtimeout, such as two hours.

In accordance with an aspect of the present application, the controlsystem 10 includes associations between individual occupants of abuilding and a set of lighting units within the building. Accordingly,rather than a user selecting a section to illuminate, each occupant ispre-associated with a set of lighting units that correspond to the workareas that the occupant would likely require during an override. Thisavoids illuminating areas not required by the occupant, thereby savingenergy, and it also associates an override instruction with a particularoccupant. In one embodiment, it permits association of a timeout foreach unit with the intended length of stay for that particular occupant.In some embodiments, a user may also be permitted to submit overriderequests for areas outside of his or her pre-associated set of lightingunits.

Reference is now made to FIG. 5, which shows a floorplan for a portionof an example building 100. The building 100 includes exterior windows102. The building 100 also has a number of interior walls dividing thefloor into various workspaces. For example, walls may define a firstoffice 104 and a second office 106. The building 100 may also include aboardroom 108 or meeting room, washrooms 110, 112, photocopy centre 114,and interior foyer 120. Access to the floor may be by elevators 116, 118opening onto the interior foyer 120.

Aside from the offices 104, 106, and other defined spaces detailedabove, general workspaces may be defined within the building 100. Inpractice, the workspaces may include cubicles, lab benches, desks, orother work areas assigned to a set of specific individuals. Theseworkspaces are indicated by shaded areas indicated by reference numerals122, 124, and 126.

FIG. 5 shows a layout of lighting units overlaid on the floorplan 100,some of which are indicated by reference numeral 130.

A building or floor is typically occupied by a tenant. In the case ofindustrial or office space, the tenant is usually a corporate employerhaving a number of employees and contractors that work in the buildingor floor. In this sense, the tenant is an occupant of the building orfloor, and the tenant includes a number of individual occupants.

In accordance with one embodiment of the present invention, eachindividual occupant of a building or floor is associated with a WorkPoint. A Work Point is a collection of individual lighting units thatmay be required by the occupant when accessing the floor or buildingoutside of normal working hours.

In one embodiment, the Work Point is made up of one or more Work Cellsand one or more Paths. A Work Cell is an area or space that theindividual may require to complete a task. A Path is an area or spaceinterconnecting two or more Work Cells or a Work Cell and an exit orentrance. Each Work Cell and Path is made up of a set of lighting units.

Reference is now made to FIG. 6, which shows the floorplan 100 of FIG.5. By way of example, a first Work Cell is designated by referencenumeral 150 and is defined by the lighting units 130 within the shadedarea indicated by numeral 150. A first Path is designated by referencenumeral 152 and a second Path is designed by reference numeral 154. EachPath 152, 154 includes the lighting units contained within thecorresponding shaded areas shown in FIG. 6. A given occupant, forexample the individual that uses the first office 104, may be associatedwith a Work Point that is made up of the first Work Cell 150 and thefirst Path 152 and second Path 154.

Within the database 16 (FIG. 1), a record for the occupant may includean association with the Work Point, such as in the form:

Occupant # Name Tenant Work_Point_1

The Work Point may be defined by a data record detailing the Work Cellsand/or Paths that make up the Work Point, such as in the form:

Work_Point_1 { Work_Cell_1 Path_1 Path_2 }

The Work Cells and Paths themselves may be defined by data recordsspecifying the lighting units they include and a light level associatedwith the override condition:

Work_Cell_1 { Unit 0298 Unit 1429 Unit 1209 .... Unit 2378 Light Level =80 } Path_1 { Unit 0294 Unit 7612 Unit 4895 .... Unit 3829 Light Level =40 } Path_2 { Unit 3745 Unit 7236 Unit 8437 .... Unit 6745 Light Level =40 }

When an occupant inputs an override request, the occupant providesidentification information. For example, the occupant may input therequest through a concierge, who inputs the occupants name and/or IDnumber into a user interface to initiate the override request.Alternatively, the occupant may input his or her name or ID numberthrough a user interface to initiate the override request. In anotherexample, the override request may be automatically initiated when theoccupant uses his or her magnetic access card to gain entry to thebuilding outside of normal business hours. The building secure accesssystem may supply identifying information to the control system, whichmay interpret the after-hours access by the occupant as an overriderequest with regard to the lighting system. Other methods and mechanismsfor inputting an override request and occupant identifying informationwill be understood by those skilled in the art.

Based on the occupant identification information, the control system mayidentify the Work Point associated with the occupant and, thus, the WorkCell(s) and Path(s) associated with the occupant. Based on the WorkCell(s) and Path(s) records, the control system may issue commands tothe lighting units designated in those Work Cell(s) and Path(s) records.For example, with regard to example Work_Cell_1 set out above, thecontrol system may instruct the addressable lighting interface to send acommand to each lighting unit in the Work_Cell_1 to switch on to 80% offull power. Similarly, each unit in Path_1 and Path_2 may be instructedto switch on to 40% power.

Reference is now made to FIG. 7, which shows another example of a WorkPoint with regard to the floorplan 100 of FIG. 5. In this example, theWork Point includes the first and second Paths 152, 154, a first WorkCell indicated by reference numeral 156, a second Work Cell indicated byreference numeral 160, and a third Path 158. The first Work Cell 156includes the lighting units within the second office 106. The closeproximity of the first office 104 and the second office 106 means thatthe same Paths 152, 154 may be used to connect the offices 104, 106 tothe entrance to the floor at the elevators 116, 118. In this example,the individual occupant may also require access to the photocopy centre114, so the Work Point includes the second Work Cell 160 within thephotocopy centre 114 and the third Path 158 that connects to the secondWork Cell 160.

In one embodiment, as exemplified by FIGS. 6 and 7, the Paths and WorkCells are arranged such that each is mutually exclusive. In other words,each lighting unit is a member of only one Path or Work Cell. WorkPoints for individual occupants may include the same Paths or WorkCells, such as in FIGS. 6 and 7, in which both Work Points include thefirst and second Paths 152, 154; however, there is no overlap betweenWork Cells or between Paths.

In some embodiments, the distinction between a Work Cell and a Path mayonly be relevant insofar as how they are managed during expiry of theoverride time. In particular, the Path lights may remain illuminated fora short period of time longer than the Work Cell lights. Byextinguishing the Work Cell lights first, the user is alerted to theexpiry of the override. The Path lights remain at least partially on. Ifthe user does not renew the override request, then the continuedillumination of the Paths allow the user sufficient light and time toexit the building or floor.

In one example embodiment, when the override time for an individualoccupant expires, half the lights in the Work Cell are extinguished,thereby alerting the user to the expiry of the override, but providingsufficient reduced illumination to allow the user to renew the overriderequest. A short time, such as ten minutes, after the expiry of theoverride time, the remaining lights in the Work Cell are extinguished.The lighting units in the Path may remain on for a further short periodof time, such as an additional ten minutes, before they too areextinguished. It will be appreciated that this effect may beaccomplished by pre-establishing the timeouts for each of the lightingunits to have this effect; i.e. by having an override time assignedspecifically to each unit to reflect the additional time for half thelights in the Work Cell and the lights in the Path. It may also beimplemented in other manners, such as by having the override timeassociated with each Work Cell or Path as the case may be and adjustingthe override time to provide for this effect. It may also be implementedby having a single override time and relying upon the subcontroller 14to recognize each lighting unit's status as member of a Path or WorkCell in determining when to instruct the lighting control interface 24to extinguish the lighting unit.

Reference is now made to FIG. 9, which shows, in flowchart form, anexample method 200 for determining or setting the lighting level of aUnit. The method 200 differs from the method 80 (FIG. 4) in that itincludes step 202, in which the control module evaluates whether anoverride is currently place that is applicable to the Unit. If, in step202, it is determined that an override condition applies to the Unit,then in step 204 the CurrentLevel is set to the override light levelsetting defined in the associated Work Path or Cell, as the case may be.In the example method 200 of FIG. 9, an override is only set if thecurrent Schedule indicates that the Units are to be off. Other examplesmay provide that an override may be put in place even when the Scheduleindicates that some or all of the Units are to be on; but that step 204will only set the CurrentLevel to the Override Level if the OverrideLevel is higher that the CurrentLevel value at step 202.

Reference is now made to FIG. 8, which diagrammatically shows a portionof the floorplan 100 of FIG. 5 with overlapping Work Points. FIG. 8shows two overlapping Work Cells: a first Work Cell 172 and a secondWork Cell 174. The first Work Cell 172 includes lighting units 176,which are only included in the first Work Cell 172, and lighting units178, which are common to both Cells 172, 174. The second Work Cell 174includes the common lighting units 178 and a set of lighting units 180that are only included in the second Work Cell 174.

To facilitate overlapping Work Points, in one embodiment the timeoutproperties related to an override instruction are transferred toindividual Units. When a user inputs an override instruction, thecontrol module populates the timeout parameters for each Unit in theuser's Work Point with the appropriate timeout value. In this manner,each Unit has an associated timeout value. If a second user inputs anoverride that would result in a later timeout, then the Units that arecommon to both the first user's Work Point and the second user's WorkPoint will have their associated timeout parameters updated with thelater timeout value.

In another embodiment, each Unit has an Event_Counter parameter thattracks how many override requests the Unit is currently subject to. TheEvent_Counter parameter is incremented each time an override instructionis received that affects the Unit. The timeout value is associated withthe user's Work Point. When the timeout value is reached, and theoverride expires, then the control module turns off any Units within theWork Point that have an Event_Counter set to 1. If a Unit'sEvent_Counter is 2 or higher, it indicates that other overrideinstructions from other Work Points still apply to those Units, and thecontrol module simply decrements the Event_Counters associated withthose Units.

Other mechanisms may also be used to track associations between Units,Work Cells, Paths, Work Points, and override instructions, as will beappreciated by those of ordinary skill in the art.

To illustrate the operation of overlapping Work Points, reference is nowmade to FIG. 10, which shows, in flowchart form, an example method 300for implementing override commands for overlapping Work Points. Insetting up the lighting system, it will be appreciated that various WorkCells and Paths are defined and associated with various Units based onthe physical layout of the facility within which the lighting system isinstalled. Work Points made up of Work Cells and Paths are defined andassociated with individual occupants.

The method 300 begins in step 302, with receipt of an overrideinstruction. As explained above, the override instruction may be inputin a variety of ways, including through a GUI interface, a wirelessmobile device, a touchtone telephone interface, through a concierge,etc. The override instruction may have a default timeout value or mayinclude a user-selected timeout value. The override instruction isassociated with a particular individual occupant.

Based on the identity of the particular individual occupant associatedwith the override instruction, the system identifies the individualoccupant's associated Work Point in step 304. In one embodiment, thismay involve looking up the associated Work Point in a look-up table ordatabase using an identification number or other identifier specific tothe individual occupant. The Work Point data retrieved by the systemidentifies the Work Cells and Paths, and thus the Units covered by theWork Point, and the override power levels for Units within the WorkCells and Paths. In step 306, the system sets the timeout parameters forthe Units within the Work Cells and Paths based on the timeout valuereceived with the override instruction. As noted earlier, the mechanismfor setting the timeout value for the various Units may include settinga timeout parameter for each Unit, setting a timeout parameter for thespecific Work Cells or Paths, or setting a timeout parameter associatedwith the Work Point. Any of these specific implementations, orvariations or combinations thereof, may be used. In the present example,it will be presumed that the timeout parameter is specific to the WorkPoint.

In step 308, the Event_Counter parameter for each Unit in the Work Pointis incremented.

In step 310, the power levels of all the Units are determined andinstructions are sent to those Units that are to be turned on, turnedoff, or set to a new dimming level. In one embodiment, the setting ofthe power levels of the Units in step 310 is carried out by way of amethod like the method 200 described in connection with FIG. 9.

The system evaluates whether an override has expired in step 312, whereit assesses whether a timeout value has expired for a Work Point. Ifnot, then the method 300 continues to step 314, wherein the systemassesses whether a new override command has been received. If so, thenthe method 300 returns to step 302 to implement the new override. Ifnot, then the method 300 cycles back to step 310. In step 310 anychanges in the applicable Schedules for the Units, or in received BoostSignals, or other factors, will be reflected in the Current Levelscalculated for each Unit. As before, any Units subject to an overrideinstruction have their Current Levels set to their Override Levels.

If, in step 312, a timeout is determined to have expired, then in step316 all the Units within the Work Point associated with the expiredoverride are turned off, unless they are also subject to anotheroverride (for overlapping Work Points). As discussed above, onemechanism for dealing with overlapping Work Points is to rely on theEvent_Counter parameter. In particular, in step 316 the system turns offany Units within the Work Point that have an Event_Counter set to 1 andthen decrements the Event_Counters of all Units within the Work Point.The method 300 then cycles back to step 310.

It will also be appreciated that, although shown separately, theimplementation of a portion of step 316 is accomplished through themethod 200 embodied in step 310. For example, the setting of the powerlevel of the Units that are to be turned off to zero may be carried outby virtue of application of the method 200 shown in FIG. 9. When step202 of the method is reached, those Units that are not subject to afurther override and that are within the Work Point of the expiredoverride with not have their Current Levels set to their overridelevels. Instead their Current Levels may be established by the ScheduledLevel, or the Minimum Level, as indicated in method 200. It will beunderstood that implementation of this condition may mean that step 202includes an evaluation of whether the Unit's Event_Counter indicatesthat it is subject to an unexpired override instruction; i.e. that it'sEvent_Counter is >0. Other mechanisms for determining whether a Unit isstill subject to an override and for resetting the power level of Unitswhose override has expired will be understood by those ordinarilyskilled in the art.

Daylight Adjustments

In another aspect, the present application describes a system forcontrolling addressable lighting units in a facility, where the systemis responsive to daylight levels in the environment exterior to thefacility.

Many existing systems include light sensors for detecting light levelsin the area of a lighting unit and adjusting the power or dimming levelof the unit accordingly. The simplest example is a sensor with athreshold. If the sensed light level falls below a threshold, then thelighting unit is turned on. If the light level rises above a (usuallydifferent) threshold, then the lighting unit turns off. In some lightingcontrol systems a collection of units may receive direct light sensorinput data from a light sensor positioned within a room or area of abuilding and wired to the units. Based on the light sensor datareceived, the lighting units may dim their light levels within the roomor area of the building.

A light sensor may be configured to a selected light level and provide afeedback signal that indicates if the sensed light level is above orbelow the selected light level. The control system may be configured toadjust the dimming levels of units in the area of the sensor to reachthe selected light level.

Reference is again made to FIG. 1 and FIG. 5. As noted above, thesubcontrollers 14 may have input ports connected to one or more sensors30. As illustrated in FIG. 5, one of the sensors may include an exteriorlight sensor 140. The exterior light sensor 140 is positioned so as tosense the ambient light level outside the building or facility. Forexample, the light sensor 140 may be mounted to an exterior wall of thebuilding, as illustrated in FIG. 5. Multiple light sensors 140 may beused, each positioned on a different side of the building, for example.

The light sensors 140 are positioned so as to provide data indicative ofthe light levels incident on the windows 102 of the building. Based onthese light levels, the control modules 20 may make an assessment of theexterior daylight intensity and consequent adjustments to the dimminglevels of the lighting units. The light sensors 140 may be hardwiredinto the lighting control system. In some other embodiments, they may bebattery operated and may communicate wirelessly with a receiverconnected to the lighting control system.

Each of the lighting units has an associated daylight saving weight(DSW) property. The DSW property describes the behavior of the unit inresponse to the exterior light levels. The DSW property for each unit ispreset depending on the physical layout of the building and itsproximity to sources of natural light, e.g. the windows. For example,those units that are located adjacent to a window may have a DSWproperty that is highly responsive to exterior light levels, indicatingthe unit should be aggressively dimmed when exterior light levels areintense. Other units, like those in work space 124, are located a fairdistance from a window 102 and may receive little natural light. Theseunits may have a DSW property set to be less responsive to exteriorlight levels. A unit with little or no exposure to natural lightsources, like a unit located in the interior foyer 120 or one of thewashrooms 110, 112, may have a DSW parameter that is non-responsive toexterior light levels.

In one embodiment, for simplicity, the light levels sensed by exteriorlight sensors 140 are quantized by the control module 20, and the DSWproperties are based on the quantization scheme. For example, exteriorlight may be quantized into five levels: DARK, FLAT, CLEAR, BRIGHT,INTENSELY BRIGHT. These terms are but one example; other terminology maybe used, and fewer or more levels of quantization may be used. Usingthis example, a unit may have a DSW property associated with lightsensor [L1] as follows:

-   -   DSW=[0 10 30 60 75]

The DSW indicates the dimming factor—the percentage of full power bywhich the unit should be dimmed under the five conditions. For example,if the scheduled power level of the unit is 80% of full power, and theexterior light sensor L1 indicates the daylight condition as BRIGHT,then the DSW indicates that, under the light conditions, the unit shouldbe reduced to 100−60=40% of full power. If the light sensor L1 indicatesthat the daylight condition is FLAT, then the DSW would result in asetting of 90% of full power, meaning that the resulting power levelwill be the 80% of full power, since it is the lowest level prescribedby the Schedule.

In another embodiment, in addition to the exterior light sensor 140, thesystem includes an interior sensor. The interior sensor provides dataindicative of the status of blinds on the windows. In one exampleembodiment, the interior sensor is a mechanical or electromechanicalsensor that direct senses whether the blinds are closed or open, or, insome cases, the degree to which the blinds are closed. In anotherexample embodiment, the interior sensor is a light sensor that providesa reading of the interior light levels which, when compared to theexterior light levels read by the exterior light sensor 140, indirectlyindicates the status of the blinds. The data from the interior sensor,and thus the status of the blinds, allows the control system to apply acorrection factor to the DSW property that would otherwise be selectedbased on the exterior light conditions. In other words, the DSWproperties are based on having fully opened blinds. The correctionfactor adjusts the DSW based on the blind status. For example, if theexterior light conditions would result in dimming a unit by 60% and theblind status is determined to be partly closed, then the dimming may beadjusted by a correction factor of, e.g., 0.5, for a resultant dimmingof 30%. It will be appreciated that the precise correction factors maybe application dependent.

Reference is made to FIG. 11, which shows, in flowchart form, an examplemethod 400 for determining or setting the lighting level of a Unit. Theexample method 400 is similar to the example methods 80 and 200 depictedin FIGS. 4 and 9, respectively; however, the method 400 also applies theDSW property of the Unit.

The steps of method 400 are similar to the steps of method 200. TheCurrentLevel of the Unit is governed by the Scheduled Level, subject toany Exceptions, as indicated in steps 84, 90, and 92. If, in the result,the Unit is off or significantly dimmed, then it may have itsCurrentLevel increased if it is subject to a Boost signal (steps 94, 96)or an Override command (steps 202, 204).

Then, in step 402, the CurrentLevel is then assessed against the levelprescribed by the DSW property for the Unit. Based on the light sensordata, an exterior light condition is identified by the control module20. As explained above, the DSW property for the Unit assigns a dimminglevel for each exterior light condition. The dimming level, or DSWLevel,indicates the level to which the Unit should be dimmed given the lightconditions. In step 402, the control module assesses whether theCurrentLevel is higher than the level prescribed by the DSW property. Ifit is already lower, then the method 400 continues to step 98.Otherwise, in step 404, the CurrentLevel is adjusted down to theDSWLevel prescribed by the DSW property for the current exterior lightconditions.

It will be appreciated that the above embodiments of a lighting controlsystem use one or more exterior sensors to obtain an indication of theexterior light conditions. Adjustments to each individual unit inresponse to the exterior light conditions are made based on a DSWproperty preset for each unit, where the DSW property is partly based onthe proximity of the unit to sources of natural light, such as windows.It will be appreciated that this configuration and method avoids thecost associated with using a plurality of light sensors in everyinterior location in an attempt to sense the actual interior lightlevels in various areas of the building, and to make adjustments togroups of units accordingly.

It will also be appreciated that one or more interior sensors may beused to determine the status of blinds, if any, and that the status ofthe blinds may be used to apply correction factors to the DSWproperties.

Conservation Demand Management

In many parts of the world, electric power is growing increasinglyexpensive and unreliable. Environmental concerns with coal firedgenerators and with alternatives, like nuclear power, have resulted inan undersupply of electrical energy sources. The consequence is thatmany electric utilities have difficulty meeting energy demands fromconsumers on the grid at peak usage times. This occurs most frequentlyin the heat of the summer months as air conditioning demands cause anincrease in electrical energy usage. Rotating brown-outs and black-outshave become a fact of life in some areas.

As a result, it has become common for electrical utilities to reachagreements with large corporate consumers regarding load shedding. Whena utility experiences an excessive demand it can issue a request to someconsumers to reduce their demand so as to avoid a blackout in thesystem. In practice, in the case of a building with a number of lightingunits, this process may include an incoming request from a utility thatthe building reduce its electrical demand by a fixed amount orpercentage, or a request that the building indicate the amount by whichit can reduce its demand. Personnel in the building may be charged withresponsibility for determining the amount by which the building canreduce demand, and for then implementing that decrease. In some cases,this may include simply dimming all lighting units in the building bysome percentage. The dimming of lighting units may be effected byinputting a command to the lighting control system to dim all units by afixed or percentage amount. In some cases, it may be effected byinputting a command to turn off various lighting units. This action maybe termed “load shedding”.

In one aspect, the lighting control system of the present application ispreconfigured to assist with optimizing the load shedding operation withminimal annoyance to users in the building.

Each Unit is assigned a load shedding weight (LSW) property. The LSWproperty indicates the extent to which the unit may be dimmed dependingon the seriousness of the conservation demand. The seriousness of theconservation demand may be viewed as escalating levels of electricsupply emergency, from a low-level soft request up to a criticalcommand. Any number of levels of quantization may be specified. In oneexample embodiment, six different conservation demand levels areassigned. Level 1 corresponds to a low level non-critical conservationdemand, under which moderate reduction of demand may be made but nothingthat would significantly annoy or inconvenience the building'soccupants. Level 6 corresponds to a critical emergency conservationdemand, under which drastic load reduction is required and a noticeabledrop in light levels will be apparent to the occupants. The conservationdemand level indicates the severity of the impact of the demandreduction being imposed on the lighting system.

The LSW property for each unit indicates the Unit's minimum power levelfor a specific conservation demand level. By way of example, threelighting units may have the following respective LSW properties:

-   -   U1 LSW=[1 80] [2 60] [4 40] [6 0]    -   U2 LSW=[1 80] [4 40] [5 0]    -   U3 LSW=[1 50] [2 20] [4 0]

The example LSW properties indicate that a conservation demand at level1 would result in 80% dimming of units U1 and U2 and a 50% dimming ofunit U3. At level 2, unit U1 could be further dimmed to 60% and unit U3could be further dimmed to 20%. At level 3, no changes would result, andat level 4 both U1 and U2 could be dimmed to 40% while unit U3 could beextinguished. Unit U2 can be extinguished at level 5 and unit U1 can beextinguished at level 6.

Accordingly, the level of the conservation demand determines the loadshedding action for each Unit in the lighting control system. Lesscritical units, like unit U3, can be dimmed and turned off under lesseremergencies, while more important units like U1 may offer less dimmingand may not be turned off unless a truly critical emergency arises. Inone aspect, this permits a building administrator to select aconservation demand command that reflects the significance of theemergency.

Referring again to FIG. 1, in one embodiment the database 16, or anothermemory within the system 10, may include a grouping of units into Areas,based on commonalities in LSW properties. Areas do not refer to theunit's location, but rather to a set of units that share an LSWproperty. For example, an Area may be defined to include all those unitshaving the property [1 80]. Areas may be used for assessing andimplementing conservation demand management functions. Using the examplegiven above for three units, the following Areas may be defined:

-   -   AREA1 [1 80]=U1, U2    -   AREA2 [1 50]=U3    -   AREA3 [2 60]=U1    -   AREA4 [2 20]=U3    -   AREA5 [4 40]=U1, U2    -   AREA6 [4 0]=U3    -   AREA7 [5 0]=U2    -   AREA8 [6 0]=U1

The system 10 may include a conservation demand management (CDM) module19. The CDM module 19 may retrieve or search Area data within thedatabase 16 or other memory in order to identify units affected by apotential conservation demand command. The CDM module 19 may also queryand obtain data regarding the Current Levels of Units affected by thepotential command from the subcontrollers 14 (through the daemons 22).Based on the Current Levels and the LSW of the Area, the CDM module 19may determine the impact of a potential command on overall demand of thesystem 10. For example, the CDM module 19 may be configured to calculatethe reduction in energy usage that would result if a conservation demandwere issued at level 5 versus level 4. It may present these results to auser, for example through the GUI display 18 or a remote user terminal32, who may then select an appropriate command. In another embodiment,the CDM module 19 may determine the command level required to obtain aparticular energy savings. For example, a user may request a loadreduction of a certain number of kilowatts, or a percentage of currentuse, and the CDM module 19 may determine the energy savings availablefrom a level 1 command, a level 2 command, etc. until it identifies acommand level sufficient to achieve the requested load reduction.

In a building, or group of buildings, the system 10 may have a number ofsubcontrollers 14 each with hundreds of lighting units, meaning that thesystem 10 includes thousands of units all with unique LSW properties. Bypre-defining Areas that list the units having common LSW properties, thecentralized CDM module 19 is capable of quickly requesting or retrievingCurrent Level information from each unit listed in an Area having acertain LSW property, meaning that the CDM module 19 can assess the“available” shedding that would be achieved by implementing that levelof conservation demand command. Alternatively, the CDM module 19 mustperform a scan of all units to identify those units that would beaffected by a particular conservation demand command and the extent towhich implementation of the command would reduce energy demands of eachunit.

Reference is now made to FIG. 12, which shows, in flowchart form, amethod 500 of conservation demand management with respect to a lightingsystem. The method 500 begins in step 502 with receipt of load sheddingrequest. The load shedding request may include load shedding criteria.The criteria may, for example, specify a target number of watts by whichdemand should be reduced. Alternatively, the criteria may specify apercentage of current usage by which demand should be reduced. Othercriteria may be used or specified. The load shedding request may bereceived by the system 10 (FIG. 1) by way of a load shedding requestcommand input by a user through the GUI display 18, a remote userterminal 32 or through any other user interface to the system 10.

As noted above, the load shedding request input to the system in step502 may be directly or indirectly based on a conservation demand requestreceived from a power authority. The conservation demand request from apower authority may in some cases specify a number of watts to be shed.In these circumstances, the method 500 may be applied to determine theconservation demand level necessary to achieve the desired loadshedding. In some other cases, the power authority may request anindication of the number of watts that the building complex is willingto shed. In these cases, the method 500 may be applied so as todetermine the number of load shedding watts available at the variousconservation demand levels.

In some embodiments, once the method 500 determines the conservationdemand level required to achieve a desired or target reduction themethod 500 may then implement conservation demand instructions, with orwithout further user instructions or confirmation.

It will be appreciated that in some embodiments the method 500 islargely implemented through the CDM module 19 (FIG. 1). The CDM module19 may be a suitably configured software program, application, process,or other construct for carrying out the steps and operations describedabove within the environment of the system 10. Nevertheless, it will beunderstood that the method 500 need not by implemented as the CDM module19 shown in FIG. 1 and may be implemented elsewhere in the system 10 aspart of another component or software program.

After the load shedding request is input in step 502, the CDM modulesets the conservation demand level (CDL) to 1 in step 504, indicatingthe lowest level of conservation demand emergency. In one embodiment,the module also clears an accumulator variable (ACC).

In step 506 the CDM module identifies Units that have LSWs containing aparameter for the current CDL. In an embodiment in which Units areorganized into Areas, the CDM module searches the Areas to identifythose Areas that relate to the current CDL. For example, at CDL=1, theCDM module identifies all Areas that relate to level 1. In the examplegiven earlier, this includes AREA1 and AREA2. The identified Areascontain a list of units having a parameter within their LSWs thatrelates to the current CDL.

In step 508, the CDM module obtains the CurrentLevel for each Unitidentified in step 506. The CurrentLevel for each Unit may be obtainedfrom the subcontrollers 14 to which the Units belong. In many cases, theCurrentLevel data may be stored locally in memory at the subcontrollers14. In some other cases, the subcontrollers 14 may update the database16 regularly with CurrentLevel data for each Unit. The precise modeldepends on the architecture of the overall system 10. In any event, theCDM module retrieves the CurrentLevel and the maximum or capacity levelfor each Unit.

In step 510, the CDM module determines what effect the current CDL wouldhave on each Unit's power use. In particular, the LSW for the Unit (orArea, if the Units are grouped into Areas), specifies a particularreduction from maximum for the given CDL. For example, it may specifythat at CDL=1 the Unit should be set to 80% of full power. TheCurrentLevel indicates the current power level of the Unit. Due to thecurrent Schedule, or an Override, or an Exception, or Daylight SavingsWeight, the CurrentLevel may be higher or lower than the level thatmight be achieved through a conservation demand instruction at thecurrent CDL. Accordingly, in step 510, for each Unit the CDM moduledetermines how much of a power saving would be available. Each Unit'savailable load shedding at the current CDL may be expressed as:

AvailPower(Unit(n, CDL)) = CurrentLevel(Unit(n)) − [LSW(Unit(n), CDL) × MaxPower(Unit(n))]

The available power (AvailPower) for a given Unit at the current CDL isthe difference between the CurrentLevel of the Unit and the level thatwould result from application of the CDL. The latter “resultant” poweris the LSW of the Unit at the current CDL times the Unit's maximum orcapacity power.

If the available power is negative, because the CurrentLevel is alreadylower than the level that would result from application of the CDL, thenthe calculation for that Unit may be ignored. This might occur if theUnit is subject to Daylight Savings Weight, or if the Unit is subject toan Exception, or if the Scheduled level is simply lower than the CDLlevel, or through other factors. In calculating the CurrentLevel, forexample using a variant of the method 80 of FIG. 4, or the method 200 ofFIG. 9, or the method 400 of FIG. 11, the lower power level (e.g. due tothe Schedule, the Exception, or the Daylight Savings Weight) will governthe determination of CurrentLevel even if the current CDL is implementedby way of a conservation demand command.

If the available power is positive, then the CDM module notes the poweravailable. In one embodiment, the CDM module adds the available power tothe accumulator (ACC) variable. As the CDM module calculates theavailable power for each unit, it continues to add the calculatedavailable power to the accumulator. After all Units have been assessed,then the accumulator contains the power available from implementing thecurrent CDL. In some embodiments, the CDM module may then display thistotal to a user, for example through the GUI display 18.

To the extent that load shedding criteria were specified with input ofthe load shedding request in step 502, the CDM module assesses whetherthose criteria are met by the current CDL in step 512. In particular,the CDM module may compare the available power specified in theaccumulator with the requested or target load shedding. If the availablepower meets or exceeds the target, then the criteria are met. If theavailable power from the current CDL is insufficient to meet the target,then the criteria are not met.

If the load shedding criteria are met at the current CDL, then themethod 500 proceeds to step 514 where it assesses whether the currentCDL results in excess shedding, i.e. if the available power is greaterthan the target. In some embodiments, a threshold may be prescribedunder which the difference is considered negligible. If the availablepower is essentially the same as the target or requested load shedding,then in step 516 the CDM module may implement the load shedding byissued a conservation demand instruction at the current CDL. Theaffected Units are then dimmed in accordance with the CDL and theirLSWs.

If there is excess shedding identified in step 514, then in step 518 theCDM module may generate a modified conservation demand instruction totry to eliminate the excess. For example, based on the ratio of thetarget dimming to the available load shedding the CDM module mayidentify the percentage of the available load shedding required to meetthe target. It may then generate a conservation demand command thatincludes the percentage, and the Units may be dimmed by their specificLSW for the current CDL multiplied by the percentage. For example, ifthe method 500 is used to reach a target load shedding of 100 kW, andthe available power at CDL=2 is 80 kW and the available power at CDL=3is 120 kW, then the CDM module may issue a conservation demand commandinstructing the Units to dim to their CDL=3 power level*83.3%(=100/120). In this example, a Unit with a LSW=[1 80] [2 70] [3 40] [50] would dim to 50% of full power since at CDL=3 the LSW indicates theUnit should dim by 60% from full power to a power level of 40%, but themodified conservation demand command indicates only 83.3% of the dimmingis required. Accordingly, the power level for the Unit is set to (fullpower*100%−((100−40)*0.833) %).

Step 518 may alternatively include other modifications to theconservation demand command in an attempt to reduce excess shedding. Forexample, the conservation demand command may only be applied to a subsetof Areas or floors or Units, which are selected on the basis that theywill provide the target amount of load shedding. Other variations willbe understood by those skilled in the art. In some cases, the method 500may not include any modified commands, and steps 514 and 518 may beeliminated.

If, in step 512, it is found that the calculated available power fromthe current CDL is insufficient to meet the target load shedding, thenthe method 500 proceeds to step 520, where it assesses whether the CDLis at a maximum emergency level (e.g. level 6, in one embodiment). Ifso, then the target amount of load shedding is unavailable from anylevel of emergency conservation action and an alert may be issued to anoperator or user. The maximum emergency level load shedding may or maynot be implemented at this time to achieve whatever load shedding isavailable despite the fact it does not meet the load shedding criteria.

If the CDL has not reached its maximum level, then the CDL isincremented in step 522. The method 500 then returns to step 506 andagain determines the available power from load shedding, but this timewith the new CDL. In this manner, the method 500 proceeds to until itdetermines the CDL that will result in a load shedding that meets thetarget.

In one embodiment, following step 512, even when the CDM moduledetermines that the current CDL provides insufficient power demandreduction to meet the target, the CDM module implements the current CDL.In other words, if the method 500 determines that CDL=1 providesinsufficient load shedding, it still results in a conservation demandcommand at CDL=1, to cause the relevant Units to dim to their LSW atCDL=1. The method 500 then returns to step 506 to determine whether theadditional power savings from CDL=2 would be sufficient to meet thetarget. In this embodiment, the target is reduced by the amount ofavailable power achieved by way of the conservation demand command atthe current CDL. For example, if the target reduction is 100 kW andCDL=1 results in available power savings of 60 kW, then a command isissued to reduce demand in accordance with CDL=1, the relevant Units aredimmed accordingly meaning that their CurrentLevels reflect CDL=1, thetarget is reset to 40 kW, and the method 500 is repeated to determinewhether moving to CDL=2 supplies the necessary additional 40 kW of powersavings.

Other implementations and variations will be appreciated by those ofordinary skill in the art. For example, those skilled in the art mayappreciate that in some instances various steps described in the methodsabove may be rearranged and performed in an alternative order, or may becombined or performed contemporaneously. In some instances, steps may beomitted or supplemented with additional steps. The preciseimplementation of each method depends, in part, upon the architecture ofthe system and the nomenclature, organization, and structure of the datarecords for the Units selected for a particular installation.

The above discussed embodiments are considered to be illustrative andnot restrictive, the scope of the invention being indicated by theappended claims rather than the foregoing description, and all changeswhich come within the meaning and range of equivalency of the claims aretherefore intended to be embraced therein.

1. A system for controlling addressable lighting units within abuilding, the building having at least one tenant, the tenant beingassociated with a plurality of occupants, the units each having one ormore light fixtures, each unit having an addressable switch connected toa control bus, the system comprising: a controller having one or morecontrol outputs for transmitting commands to the units via the controlbus and being configured to receive an instruction associated with oneof the occupants; and a memory device storing a unit record for eachunit, each record specifying unit-specific properties, an occupantrecord for each of the occupants, each occupant record identifying oneof said occupants and associating a subset of the units with theoccupant, wherein the controller is configured to generate the commandsto the subset of the units in response to the light instruction andbased on the association in the occupant record between said one of theoccupants and the subset of the units.
 2. The system claimed in claim 1,wherein said memory stores one or more Work Point definitions, each WorkPoint definition identifying one or more units, and wherein saidoccupant record contains an association between said one of theoccupants and one of said Work Point definitions, and wherein saidsystem includes an override module configured to receive an overridecommand associated with said one of the occupants and to cause saidunits within said one of said Work Point definitions to be set to anoverride power level based on said association.
 3. The system claimed inclaim 2, wherein said memory is configured to store a plurality of WorkCells definitions, each Work Cell definition identifying a plurality ofunits, and to store a plurality of Path definitions, each Pathdefinition identifying another plurality of units, and wherein each WorkPoint definition identifies one or more Work Cell definitions and one ormore Path definitions.
 4. The system claimed in claim 3, wherein saidWork Cell definitions and said Path definitions are configured such thatunits within said Work Cell definitions are subject to the overridepower level for an override time shorter than the units within the Pathdefinitions.
 5. The system claimed in claim 2, wherein a first of theWork Point definitions contains one or more units in common with asecond of the Work Point definitions, and wherein the override module isconfigured to update an event counter associated with each unit affectedby the override command in response to receipt of the override command.6. The system claimed in claim 2, wherein a first of the Work Pointdefinitions contains one or more units in common with a second of theWork Point definitions, and wherein the override module is configured toupdate an override time out value associated with each unit affected bythe override command in response to receipt of the override command. 7.The system claimed in claim 1, wherein the memory stores one or moreschedules, each unit being associated with one schedule, and whereineach schedule defines, for specified times, a level for its associatedunits, and wherein the controller includes a control module configuredto determine a scheduled level for each of the units based on theschedules and a current time.
 8. The system claimed in claim 7, whereinthe memory stores one or more exception parameters each defining anexception level and a condition, and wherein the control module isfurther configured to test the condition to determine whether anexception applies to at least one unit and, if so, to adjust the levelof the at least one unit based on the exception level.
 9. The systemclaimed in claim 7, wherein the control module further includes anoverride module configured to receive an override command associatedwith said one of said occupants and to cause the associated units withinsaid occupant record to be set to an override level.
 10. The systemclaimed in claim 7, further including an exterior light sensor fordetermining an ambient light level reading external to the building, andwherein each of said unit records includes a daylight dimming parameter,and wherein the control module is configured to adjust the level foreach unit based on its daylight dimming parameter and the ambient lightlevel reading.
 11. The system claimed in claim 7, wherein each of saidunit records includes a load shedding parameter for one or moreconservation demand levels, and wherein the control module is configuredto receiving a conservation command specifying one of the conservationdemand levels, and wherein the control module is configured to adjustthe level for each unit based on its load shedding parameter for thespecified one of the conservation demand levels.
 12. The system claimedin claim 1, further comprising a master controller, and wherein thecontroller comprises at least one subcontroller having a control moduleand a daemon, the daemon being configured to manage communicationsbetween the control module, the lighting units, and the mastercontroller, and wherein the master controller and at least onesubcontroller are interconnected via a data network.
 13. A method forsetting light levels for addressable lighting units within a building,the building having at least one tenant, the tenant being associatedwith a plurality of occupants, the units each having one or more lightfixtures, each unit having an addressable switch connected to a controlbus, the method comprising: receiving a lighting instruction associatedwith one of the occupants; reading an occupant record identifying saidone of the occupants and associating said one of the occupants with asubset of the units; and generating commands to the set of units inresponse to the lighting instruction and based on the association in theoccupant record.
 14. The method claimed in claim 13, wherein theoccupant record contains an association between said one of theoccupants and a Work Point definition, the Work Point definitionidentifying said subset of units, and wherein reading the occupantrecord includes reading the Work Point definition, and wherein receivingthe lighting instruction comprises receiving an override commandassociated with said one of the occupants, and wherein generatingcommands comprises sending commands to said subset of units within theWork Point definition to be set to an override power level based on saidassociation.
 15. The method claimed in claim 14, wherein the Work Pointdefinition identifies one or more Work Cell definitions and one or morePath definitions, each Work Cell definition identifying a plurality ofunits and each Path definition identifying another plurality of units,and wherein reading the Work Point definition includes reading said oneor more Work Cell definitions and said one or more Path definitions toidentify said subset of units.
 16. The method claimed in claim 15,wherein said Work Cell definitions and said Path definitions areconfigured such that units within said Work Cell definitions are subjectto the override power level for an override time shorter than the unitswithin the Path definitions.
 17. The method claimed in claim 14, whereinthe Work Point definition is a first Work Point definition containingone or more units in common with a second Work Point definition, thelighting instruction being associated with a first occupant who isassociated with the first Work Point, and further including receiving asecond lighting instruction from a second occupant associated with thesecond Work Point, and in response to the first lighting instructionincrementing event counters associated with each of the units in thefirst Work Point, and in response to the second lighting instructionincrementing event counters associated with each of the units in thesecond Work Point.
 18. The method claimed in claim 14, wherein the WorkPoint definition is a first Work Point definition containing one or moreunits in common with a second Work Point definition, the lightinginstruction being associated with a first occupant who is associatedwith the first Work Point, and further including receiving a secondlighting instruction from a second occupant associated with the secondWork Point, and in response to the first lighting instruction settingoverride timeout values associated with each of the units in the firstWork Point, and in response to the second lighting instruction settingoverride timeout values associated with each of the units in the secondWork Point.
 19. The method claimed in claim 13, wherein each unit isassociated with a schedule, and wherein each schedule defines, forspecified times, a level for its associated units, and the methodfurther includes determining the scheduled level for each of the unitsbased on their associated schedule and a current time, and setting thelevel of each unit based on its scheduled level.
 20. The method claimedin claim 19, further including overriding the scheduled level for one ormore units based on the received lighting instruction and the generatedcommands.
 21. The method claimed in claim 19, wherein one or moreexception parameters each define an exception level and a condition, andthe method further includes testing the condition to determine whetheran exception applies to at least one unit and, if so, to adjusting thelevel of the at least one unit based on the exception level.
 22. Themethod claimed in claim 19, wherein each of said unit records includes adaylight dimming parameter, and the method further includes receiving anambient light level reading from an exterior light sensor external tothe building and adjusting the level for each unit based on its daylightdimming parameter and the ambient light level reading.
 23. The methodclaimed in claim 19, wherein each of said unit records includes a loadshedding parameter for one or more conservation demand levels, andwherein the method further includes receiving a conservation commandspecifying one of the conservation demand levels, and calculating anadjusted level for each unit based on its load shedding parameter forthe specified one of the conservation demand levels.
 24. A method forsetting light levels for addressable lighting units within a building,the method comprising: associating a schedule with each lighting unit,each associated schedule defining power levels for the unit for specifictimes of day; and for each lighting unit, determining a current powerlevel for the unit based on its associated schedule and a current timeof day, and instructing the unit to use the current power level.
 25. Themethod claimed in claim 24, further including receiving an overrideinstruction associated with an individual, reading an associationbetween the individual and particular lighting units, and whereindetermining the current power level includes overriding the associatedschedule for the particular lighting units to set the current powerlevel to an override power level, and instructing the unit comprisesinstructing the unit to use the override power level.
 26. The methodclaimed in claim 24, wherein each of said units has an associateddaylight dimming parameter, and the method further includes receiving anambient light level reading from an exterior light sensor external tothe building, and wherein determining the current power level furtherincludes adjusting the current power level for each unit based on itsdaylight dimming parameter and the ambient light level reading.
 27. Themethod claimed in claim 24, wherein each of said units has an associatedload shedding parameter for one or more conservation demand levels, andwherein the method further includes receiving a conservation commandspecifying one of the conservation demand levels, and whereindetermining the current power level further includes adjusting thecurrent power level for each unit based on its load shedding parameterfor the specified one of the conservation demand levels.
 28. A systemfor setting light levels for addressable lighting units within abuilding, the system comprising: means for associating a schedule witheach lighting unit, each associated schedule defining power levels forthe unit for specific times of day; means for determining, for eachlighting unit, a current power level for the unit based on itsassociated schedule and a current time of day; and means for instructingthe unit to use the current power level.
 29. A system for controllingaddressable lighting units within a building, the units each having oneor more light fixtures, each unit having an addressable switch connectedto a control bus, the system comprising: a light control interfacehaving one or more control outputs for transmitting commands to theunits via the control bus; a control module for determining a powerlevel for each unit and for causing said light control interface to sendpower level commands to said units; a light sensor located external tothe building and having an output in communication with said controlmodule for providing light level data to said controller; and a memorydevice storing a unit record for each unit, each record specifyingunit-specific properties including a daylight savings weight, whereinthe daylight savings weight associates light levels with power levelsfor the unit, wherein said control module include a component fordetermining a daylight level based on said light level data and acomponent for determining said power level for each unit based upon saiddaylight level wherein said power level is based on one of said lightlevels corresponding to said daylight level.
 30. A system forcontrolling addressable lighting units within a building, the units eachhaving one or more light fixtures, each unit having an addressableswitch connected to a control bus, the system comprising: a lightcontrol interface having one or more control outputs for transmittingcommands to the units via the control bus; a control module fordetermining a power level for each unit and for causing said lightcontrol interface to send power level commands to said units; a memorydevice storing a unit record for each unit, each record specifyingunit-specific properties including a load shedding weight, wherein theload shedding weight associates emergency levels with power levels forthe unit; and a conservation demand module for implementing conservationdemand instructions, the module comprising a component for receiving aconservation demand associated with a selected one of said emergencylevels, and for causing said control module to set said power levels forat least some of said units based upon said power levels associated withsaid selected one of said emergency levels.